Singapore Cn2 Server Recommended Performance Evaluation Report In Multi-line Access Scenario

1. overview and test objectives

overview: the goal of this article is to evaluate the real performance of the cn2 server deployed in singapore under multi-line (china telecom/unicom/china mobile and international lines) access, and give recommendations and operational steps. small segment: test dimensions: delay, jitter, packet loss, downlink/uplink bandwidth, tcp throughput, http response. tested environment assumptions: singapore physical machine or vps, cn2 line label (gia/gt).

2. required environment and tools

preparation list: 1) a singapore cn2 server (root authority), ubuntu 20.04+ or centos 7/8 is recommended; 2) multiple test nodes: domestic vps (one for china telecom/china unicom/china mobile), hong kong or southeast asia vps; 3) tools: iperf3, mtr, traceroute, ping, speedtest-cli, curl, httping, tcpdump; 4) test script (commands provided later). small segmentation: make sure the firewall opens the corresponding port (iperf3 defaults to 5201, http 80/443).

3. server initial configuration steps (ssh login and basic settings)

step 1: log in to the server using ssh: ssh root@your_server_ip. step 2: update the system: debian/ubuntu: apt update && apt -y upgrade; centos: yum -y update. step 3: install common tools: debian/ubuntu: apt -y install iperf3 mtr traceroute curl tcpdump git; centos: yum -y install iperf3 mtr traceroute curl tcpdump git. step 4: set time synchronization and shut down unnecessary services (systemctl disable apache2, etc.).

4. confirm the cn2 line and routing information (how to determine if it is cn2 gia/gt)

steps: use traceroute and bgp routing to view. command examples: traceroute -n 1.1.1.1; mtr --report -n 1.1.1.1. small segments: look at the routing as number and hop count - cn2 will usually go into the telecom backhaul and show as4837/as17968, etc.; ask the idc or vendor if the bandwidth is labeled "cn2 gia/gt". at the same time, whois can be used to query the peer asn: whois 1.1.1.1.

5. basic connectivity test (ping/traceroute/mtr)

step 1: ping different domestic test points from the singapore server: ping -c 10 202.97.33.33 (telecom), ping -c 10 202.106.0.20 (china unicom), ping -c 10 211.136.17.107 (mobile). step 2: traceroute -n to the target, observe the delay of the first hop to the last hop and whether there are abnormal hops. step 3: mtr --report -n -c 100 target_ip, record packet loss trends and fluctuations. small segmentation: it is recommended to save the results to a file: mtr --report -n -c 100 target_ip > mtr_report.txt.

6. bandwidth and throughput test (iperf3)

step 1: start the iperf3 server on the domestic test node: iperf3 -s -p 5201. step 2: initiate a test on the singapore server as a client: iperf3 -c domestic node ip -p 5201 -p 8 -t 60 output to file: iperf3 -c xxxx -p 5201 -p 8 -t 60 | tee iperf_result.txt. step 3: test single-threading and multi-threading (-p parameter) respectively, and record upstream/downstream (run -r on the server side). small segmentation: multiple tests are performed three times each in different time windows (peak and off-peak) and averaged.

7. http/https access performance test (httping and curl)

step 1: deploy a simple static site (nginx) on the machine under test and monitor 80/443. step 2: use httping to test the concurrency delay: httping -c 100 -t 30 -h "user-agent: test" http://your_server_ip/. step 3: use curl to test ttfb: curl -o /dev/null -s -w "%{time_starttransfer}\n" http://your_server_ip/. small segmentation: combine ab or wrk to do concurrent stress testing: wrk -t2 -c100 -d30s http://your_server_ip/.

8. cross-operator and cross-region comparative testing methods

steps: execute the same iperf3, mtr, httping tests on different operator nodes (telecom/china unicom/china mobile). small segment: unified test script sample: bash run_tests.sh includes ping, mtr, iperf3, httping and collects csv. comparison points: average delay, 99% delay, packet loss rate, bandwidth peak.

9. data recording and reporting templates (how to organize test results)

key points of the template: 1) test time and node list; 2) raw output of each test item (file or screenshot attached); 3) indicator table: avg rtt, p99 rtt, packet loss %, jitter (ms), iperf throughput (upstream and downstream); 4) conclusion and suggestions. small segmentation: it is recommended to export the indicator to csv, and then use excel/google sheets to draw the delay versus time curve and histogram.

10. frequently asked questions and network optimization suggestions

optimization steps: 1) enable bbr: echo "net.core.default_qdisc=fq" >> /etc/sysctl.conf && echo "net.ipv4.tcp_congestion_control=bbr" >> /etc/sysctl.conf && sysctl -p on linux; 2) adjust tcp window: sysctl -w net.ipv4.tcp_rmem="4096 87380 6291456" etc.; 3) check mtu and enable gro/lro; 4) distribute static resources at the cdn layer to reduce the pressure of long connections. small segment: in case of jitter or packet loss, mainly check the link quality or the upstream operator node, and provide the mtr/traceroute results to the supplier to request route optimization or appeal.

11. suggestions for purchasing cn2 servers in singapore (configuration and supplier selection)

recommended points: 1) give priority to the bandwidth or dedicated line marked with "cn2 gia", gia performs best in mainland china; 2) select cpu/memory according to business needs: lightweight web 2vcpu/4gb is enough, traffic/proxy type recommends 4vcpu+8gb; 3) bandwidth type: when measuring shared bandwidth, pay attention to bandwidth deduction and peak difference, preferably guaranteed bandwidth or dedicated line. small segment: ask the supplier to see if it provides domestic test ip (looking glass) or routing strategy instructions.

12. sample evaluation conclusion and decision-making reference

sample conclusion: under the same configuration, the telecom backhaul delay of cn2 gia is generally 20-50ms lower and the packet loss rate is close to 0; the backhaul of china unicom/china mobile is very different, so isp-by-isp testing is required; if the business relies on mainland users and is mainly telecom, please give priority to cn2 gia and ask the supplier to provide routing test points and sla before deployment. small segment: decision-making reference: use p99 delay and packet loss as the main sla indicators, rather than a single test of peak bandwidth.

13. question: what is the common delay for chinese users from singapore’s cn2 server?

q: what is the common delay for chinese users from singapore’s cn2 server?

a: a: normally, the round-trip delay (rtt) of cn2 gia from singapore to china telecom nodes is roughly in the 60-120ms range, which fluctuates depending on the specific landing node (beijing/shanghai/guangzhou) and time period; cn2 gt or ordinary international links are usually 20-50ms higher or worse. the actual delay needs to be confirmed after doing mtr/ping multi-point sampling in the target city using the method in this article.

14. question: how can i tell whether my server is really using the cn2 line?

q: how can i tell if my server is really using the cn2 line?

answer: answer: you can observe the intermediate hop count and home asn through traceroute/mtr (use whois or view the as information of each hop ip). commonly associated asn and routing features of cn2 include china unicom/telecom's proprietary asn paths, and the intermediate hops from domestic backhaul to your ip will appear as telecom core nodes. if necessary, ask the supplier for bgp announcement and routing diagrams or look at the looking glass test page provided by the supplier.

15. question: what misunderstandings should be avoided when doing testing?

q: what misunderstandings should be avoided when doing testing?

answer: answer: common misunderstandings include only doing a single test, only testing a single operator or time period, ignoring the impact of concurrency and long tcp connections, and not disabling intermediate cache, resulting in inaccurate http tests. it is recommended to test on multiple nodes, multiple time periods, and multiple concurrency times and retain the original logs to draw reliable conclusions.